Voltar 
Gartner made an interesting prediction just a few years ago: “Through 2025, 99% of cloud security failures will be the customer’s fault.” Practically every single cloud security failure can be fairly described as a misconfiguration of one kind or another. The 2025 end is kind of arbitrary, really; the prediction is likely to be true until the end of time.
In my previous article, I discussed targeting these misconfigurations at their root. Now, I’ll examine how the cloud has changed our sense of control and explore another important type of configuration-related risk to mitigate.
Greater abstraction, less control
Clouds aren’t the cheapest technology or the easiest to manage. However, they are certainly a lot more agile than provisioning stuff on-premises and waiting months for all of the hardware to be deployed and the software to get installed.
Clouds are essentially increasing layers of abstraction. When everything was on-premises, organizations could control the entirety of IT. When infrastructure moved to the cloud, organizations gave up hands-on control of the lower levels: the building, the physical network, the racks, and all the physical servers. The actual controls now start just above the hypervisor: virtual machines, middleware, applications, data and users.
When organizations move out by one more degree of abstraction to platform-as-a-service (PaaS), they’re giving up control of the operating system. Then, if they go all the way to the highest level of abstraction — i.e., software-as-a-service (SaaS) — they have also given up control of the application. The only things left in an organization’s control are protecting the data itself and defining how people access it.
One might assume that the cloud would be easier just because there is less to control, but the reality has turned out to be very different.
Public cloud access control
In general, getting your access control model correct even in only one of the public clouds is a daunting task — but few modern businesses place everything into just one cloud. Most companies spread workloads across multiple cloud providers.
The providers use constructs and terminology in slightly different ways from each other, so it’s not really portable from platform to platform. (They all generally implement the same principles but use different lexicons.) There are some conceptual differences as well. Nevertheless, every object in a public cloud will be accessed by some kind of security principle, such as a user or a service, so getting your access control list right for every object is the crucial first step.
The major IaaS/PaaS providers already offer native CSPMs, and it’s sensible for companies using only one provider to start with that provider’s product. But most businesses sprinkle their workloads across multiple providers. For this reason, I suggest evaluating a third-party CSPM. If you’re in a regulated industry, favor vendors with frameworks tailored for that. Look for products that visualize flows and relationships between resources, where misconfigurations often lurk. If you opt for automatic remediation, ensure the product runs completely within the security context of your cloud workloads and doesn’t require creating a read/write account for the vendor.
CSPM tools can assess hundreds of different settings, including access controls, across thousands of different object types compared against various baselines. This helps organizations understand where they have already applied controls and also the areas where they could use improvement.
These tools are designed to help organizations reduce risk. When that risk is reduced, the likelihood of being breached is also reduced — as is all the subsequent fallout for the company. CSPM has become almost a requirement because it has proven to be an effective risk-reduction tool that can help overcome some of the inherent complexity that comes with being a multicloud organization.
Checking cloud infrastructure and applications for exploitable weaknesses
CSPM tools evaluate the security posture of an application’s environment. But what about the security of the actual application code?
Now, we’ve entered the domain of code-scanning tools. Some products also offer the ability to make a copy of the entire execution environment, including the application code, and then probe it in various ways to try to make it misbehave. When software is written, two kinds of bugs frequently materialize. Ordinary bugs manifest as behavior that you’re expecting but, for some reason, isn’t working. Most developers are adept at finding and fixing such bugs, and good code scanners simplify the task even more.
The other kind of bug manifests as behavior that you aren’t expecting at all. Another name for this kind of bug is vulnerability, and such bugs can be quite difficult to find. For example, imagine a simple input field that offers a menu — “Enter one to play, enter two to end the program.” But what happens when someone enters “-999.99?” You didn’t check for this unexpected input and your program may behave in a way you didn’t anticipate — and maybe this misbehavior creates an advantage for an attacker.
Many cloud-using organizations have adopted infrastructure-as-code practices, where the sequences to provision infrastructure are expressed in a form of programming language. Vulnerabilities may arise in this code, too. While a few CSPM tools can check for these kinds of critical vulnerabilities, scanning infrastructure-as-code recipes requires a dedicated tool in general. They figure out if there are mistakes in your recipes that can create advantages for an attacker to exploit.
The biggest obstacle to deploying scanning tools may be obtaining developer buy-in. Developers might perceive them as yet another task that interrupts their flow without benefit. Incorporating the scanning process into existing tools allows developers to fix security vulnerabilities right away, ultimately saving time and money — it’s far more costly to fix a vulnerability in production. When evaluating products, compatibility with existing environments and pipelines should be the first capability you investigate.
We’ve examined three mechanisms for reducing the most common kinds of risks: CSPM, application scanning, and infrastructure-as-code scanning. It’s reasonable to assume that with the right tools organizations can configure and run their clouds correctly, and therefore significantly reduce the likelihood of a cloud security problem — and the likelihood of making the news. This is becoming increasingly important because clouds are complicated — and people are using a lot of them.
This article was originally published by Forbes Tech Council.
Leia o Blog